Tools and Techniques for Preliminary Sizing of Transaction Processing Applications

to the success or failure Sizing transaction of a business, based on the processing systems level of performance the correctly is a difficult application provides. In task. By nature, transaction processing, transaction processing poor application applications are not performance can translate predefined and can vary directly into lost from the simple to the revenues. complex. Sizing during The risk of implementing the analysis and design a transaction processing stages of the application application that performs development cycle is poorly can be minimized particularly difficult. by estimating the proper It is impossible to measure system size in the early the resource requirements stages of application of an application which is development. Sizing not yet written or fully estimation includes implemented. To make sizing configuring the correct easier and more accurate processor and proper in these stages, a sizing number of disk drives and methodology was developed controllers, given the that uses measurements from characteristics of the systems on which industryapplication. standard benchmarks have The sizing of transaction been run and employs processing systems is a standard systems analysis difficult activity. Unlike techniques for acquiring traditional applications sizing information. These such as mail, transaction metrics are then used to processing applications predict future transaction are not predefined. Each resource usage. customer's requirement Introduction is different and can The transaction processing vary from simple to marketplace is dominated complex. Therefore, by commercial applications Digital chose to develop that support businesses. a sizing methodology that These applications specifically meets the contribute substantially unique requirements of transaction processing Digital Technical Journal Vol. 3 No. 1 Winter 1991 1 Tools and Techniques for Preliminary Sizing of Transaction Processing Applications customers. The goal The third principle is that of this effort was to the sizing methodology develop sizing tools and must employ tools and techniques that would help techniques appropriate marketing groups and design to the current stage of consultants in recommending the customer's application configurations that meet design cycle. Early in the the needs of Digital's effort to develop a sizing customers. Digital's methodology, it was found methodology evolved over that a distinction must be time, as experience was made between preliminary gained in dealing with sizing and sizing during the real-world problems later stages of the of transaction processing application development system sizing. cycle. Preliminary sizing The development of occurs during the analysis Digital's transaction and design stages of the processing sizing application development methodology was guided cycle. Therefore, no by several principles. application software exists The first principle is which can be measured. that the methodology Application software does should rely heavily upon exist in later stages of measurements of Digital the application development systems running industrycycle, and its measurement standard transaction provides valuable input processing benchmarks. for more precise sizing These benchmarks provide activities. valuable data that For example, if a customer quantifies the performance is in the analysis or characteristics of design stages of the different hardware and application development software configurations. cycle, it is unlikely that The second principle is estimates can be obtained that systems analysis for such quantities as methodologies should be paging rates or memory used to provide a framework usage. However, if the for acquiring sizing application is fully information. In particular, implemented, then tools a multilevel view of a such as the VAXcluster customer's business is Performance Advisor (VPA) adopted. This approach and the DECcp capacity recognizes that a manager's planning products can be view of the business used for sizing. These functions performed by an tools provide facilities organization is different for measuring and analyzing from a computer analyst's data from a running system view of the transaction and for using the data as processing activity. The input to queuing models. sizing methodology should accommodate both these views. 2 Digital Technical Journal Vol. 3 No. 1 Winter 1991 and Techniques for Preliminary Sizing of Transaction Processing Applications The term sizing, as used used to describe the work in this paper, refers to performed by the business. preliminary sizing. The The Sizing Metrics and paper presents the metrics Sizing Formulas sections and algebra used in the describe the algorithms sizing process for DECtp that use platform and applications. It also business metric information describes the individual to perform transaction tools developed as part processing system sizing. of Digital's transaction processing sizing effort. Platforms Sizing The term platform is used in transaction processing The purpose of sizing sizing methodology to tools is twofold. First, encompass general customer sizing tools are used to preferences for the select the appropriate hardware and software system components and to upon which the transaction estimate the performance processing application will level of the system in run. terms of device utilization The hardware platform and user response times. specifies the desired Second, sizing tools bridge topology or processing the gap between business style. For example, specialists and computer processing style includes a specialists. This bridge centralized configuration translates the business and a front-end and backunits into functions that end configuration as are performed on the system valid alternatives. The and, ultimately, into hardware platform may also units of work that can be include specific hardware quantified and measured in components within the terms of system resources. processing style. (In this In the sections that paper, the term processor follow, a number of refers to the overall important elements of processing unit, which the sizing methodology may be composed of multiple are described. The first CPUs.) of these elements is the The software platform platform on which the identifies the set of transaction processing layered products to be system will be implemented. used by the transaction It is assumed that the processing application, customer will supply with each software product general preferences for identified by its name the software and hardware and version number. In configuration as part of the transaction processing the platform information. environment, a software The Levels of Business platform is composed of Metrics section details the transaction processing the multilevel approach monitor, forms manager, Digital Technical Journal Vol. 3 No. 1 Winter 1991 3 Tools and Techniques for Preliminary Sizing of Transaction Processing Applications database management system, application language, and operating system. usage requires that a set Different combinations of metrics be defined. of software platforms may These metrics reflect the be configured, depending business activity and the on the hardware platform system load. The business used. A centralized metrics are the foundation configuration contains all for the development the software components of several transaction on the same system. A processing sizing tools and distributed system is for a consistent algebra comprised of a front-end that connects the business processor and a backunits with the computer end processor; different units. software platforms may The business metrics exist on each processor. are natural forecasting units, business functions, Levels of Business Metrics transactions, and The term business metrics the number of I/Os refers collectively to the per transaction. The various ways to measure relationship among these the work associated with levels is shown in Figure a customer's business. 1. In general, a business In this section, various may have one or more levels of business metrics natural forecasting units. are identified and the Each natural forecasting relationship between unit may drive one or metrics at different more business functions. A levels is described. [1] business function may have As mentioned earlier, the multiple transactions, and levels correspond to the a single transaction may multilevel view of business be activated by different operation typically used business functions. Every for systems analysis. The transaction issues a organization or personnel variety of I/O operations most interested in a metric to one or more files, in relation to its business which may be physically operation is noted in the located on zero, one, or discussion of each metric. more disks. This section discusses the business The decomposition of metrics but does not the business application discuss the physical requirements into distribution of I/Os components that can be across disks, which is counted and quantified an implementation-specific in terms of resource item. A natural forecasting unit generally uses a volume is a macrolevel indicator indicator to measure of business volume. (It is the level of success also called a key volume of the business. The indicator.) A business volume is often measured 4 Digital Technical Journal Vol. 3 No. 1 Winter 1991 and Techniques for Preliminary Sizing of Transaction Processing Applications in time intervals that by a user. Each of the reflect the business interactions mentioned in cycle, such as weekly, the above business function monthly, or quarterly. is a transaction. The For example, if business measurement metric for a volume indicators were transaction is the number "number of ticket sales of transaction occurrences per quarter," or "monthly per business function. production of widgets," Transactions may be used then the corresponding by low-level managers to natural forecasting units track the activity of their would be "ticket sales" groups. and "widgets." Natural The bulk of commercial forecasting units are used applications involves by high-level executives the maintaining and to track the health of the moving of information. overall business. This information is data Business functions are that is often stored on a logical unit of work permanent storage devices performed on behalf of a such as rotational disks, natural forecasting unit. solid state disks, or For example, within an tapes. An I/O operation airline reservation system, is the process by which a common business function a transaction accesses might be "selling airline that data. The measurement tickets." This business metric for the I/O profile function may consist of is the number of I/O multiple interactions with operations per transaction. the computer (e.g., flight I/O operations by each inquiry, customer credit transaction are important check). The completion to programmers or system of the sale terminates analysts. the business function, In addition to issuing and "airline ticket" acts I/Os, each transaction as a natural forecasting requires a certain amount unit for the enterprise of CPU time to handle selling the tickets. The forms processing. (Forms measurement metric for processing time is not business functions is illustrated in Figure 1.) the number of business The measurement metric function occurrences per for forms processing time hour. Business functions is the expected number of may be used by middlefields. The number of input level managers to track and output fields per form the activity of their are important metrics for departments. users of a transaction A transaction is an processing application or atomic unit of work programmer/system analysts. for an application, and transaction response time is the primary performance measure seen Digital Technical Journal Vol. 3 No. 1 Winter 1991 5 Tools and Techniques for Preliminary Sizing of Transaction Processing Applications By collecting information directly into decreased about a transaction productivity and lost processing application revenues. at various levels, highWhen a customer generates a level volume indicators formal Request For Proposal are mapped to low-level (RFP), the performance units of I/O activity. This goals for the transaction mapping is fundamental to processing system typically the transaction processing are specified in detail. sizing methodology. The specification of goals Performance goals play makes it easier to define a particularly important the performance bounds. For role in the sizing of customers who supply only transaction processing general performance goals, systems. [2] The major it is assumed that the categories of performance performance goal takes the goals commonly encountered form of bounds for device in the transaction utilizations. processing marketplace are Overall response time bounds for consists of incremental o Device utilization(s) contributions by each major o Average response time component of the overall for transactions system: o Response time quantiles o Front-end processor for transactions o Back-end processor For example, a customer o Communications network might specify a required o Disk subsystem processor utilization of less than 70 percent. Such A main objective in a constraint reflects the this approach to sizing fact that system response was to identify and time typically rises use specific metrics dramatically at higher that could be easily processor utilizations. counted for each major A common performance component. For instance, goal for response time the number of fields per is to use a transaction's form could be a metric average response time and used for sizing frontresponse time quantiles. end processors because For example, the proposed that number is specific system should have an and easily counted. As average response time of the path of a transaction x seconds, with 95 percent is followed through the of all responses completing overall system, the units in less than or equal to of work appropriate for y seconds, where x is each component become less than y. Transaction clear. These units become response times are crucial the metrics for sizing for businesses. Poor that particular component. response times translate The focus of this paper is on processor sizing 6 Digital Technical Journal Vol. 3 No. 1 Winter 1991 and Techniques for Preliminary Sizing of Transaction Processing Applications with bounds on processor generated by a transaction utilization. Processors provides a good prediction generally constitute of the required amount the major expense in any of CPU processing. [3] proposed system solution. Numerous industry-standard Mistakes in processor benchmark tests for product sizing are very expensive positioning were run on to fix, both in terms of Digital's processors. These customer satisfaction and processors were configured cost. as back-end processors in a Sizing Metrics distributed configuration with different software Transaction processing platforms. applications permit a large The base workload for number of users to share this benchmark testing is access to a common database currently the Transaction crucial to the business and Processing Performance usually residing on disk Council's TPC Benchmark memory. In an interactive A (TPC-A, formerly the transaction processing DebitCredit benchmark). environment, transactions [4,5,6] The most complete generally involve some set of benchmark testing number of disk I/O was run under Digital's VAX operations, although the ACMS transaction processing number is relatively small monitor and VAX Rdb/VMS compared to those generated relational database. by batch transaction Therefore, results from processing applications. this software platform on CPU processing also all Digital processors were is generally small and used to compute the first consists primarily of sizing metric called the overhead for layered base load factor. transaction processing software products. Although The base load factor these numbers are small, is a high-level metric they did influence the that incorporates the sizing methodology in contribution by all layered several ways. software products on the Ratings for relative back-end processor to the processor capacity in a total CPU time per I/O transaction processing operation. Load factors are environment were developed computed by dividing the to reflect the ability of a total CPU utilization by processor to support disk the number of achieved disk I/O activity (as observed I/O operations per second. in benchmark tests). (The CPU utilization is In addition, empirical normalized in the event studies of transaction that the processor is a processing applications Symmetrical Multiprocessing showed that, for purposes [SMP] system, to ensure of preliminary sizing, that its value falls within the number of disk I/Os the range of 0 to 100 percent.) The calculation Digital Technical Journal Vol. 3 No. 1 Winter 1991 7 Tools and Techniques for Preliminary Sizing of Transaction Processing Applications of load factor yields selected DECtp software the total CPU time, in platform. centiseconds (hundredths To estimate an appropriate of seconds), required to intensity factor for a support an application's nonexistent application, single physical I/O judgment and experience operation. with similar applications The base load factors are required. However, give the CPU time per measured cases from a I/O required to run the range of DECtp applications base workload, TPC-A, on shows relatively little any Digital processor in variation in intensity a back-end configuration factors. Guidelines to using the ACMS/Rdb. The help determine intensity CPU time per I/O can be factors are included in the estimated for any workload. documentation for Digital's This generalized metric is internally developed called the application load transaction processing factor. sizing tools. To relate the base load The work required by any factors to workloads transaction processing other than the base, application is composed of an additional metric two parts: the application was defined called the /database and the forms intensity factor. The management. This division metric calculation for of work corresponds to what the intensity factor occurs in a distributed is the application load configuration, where the factor divided by the forms processing is offbase load factor. The loaded to one or more value in using intensity front-end processors. factors is that, once Load factors and intensity estimated (or calculated factors are metrics that for running applications), were developed to size intensity factors can be the application/database. used to characterize any To estimate the amount application in a way that of CPU time required can be applied across all for forms management, a processor types to estimate forms-specific metric is processor requirements. required. For a first-cut Intensity factors vary approximation, the expected based on the software number of (input) fields is platform used. If a used as the sizing metric. software platform other This number is obtained than a combined VAX ACMS easily from the businessand VAX Rdb/VMS platform level description of the is selected, the estimate application. of the intensity factor Sizing Formulas must be adjusted to reflect the resource usage characteristics of the 8 Digital Technical Journal Vol. 3 No. 1 Winter 1991 and Techniques for Preliminary Sizing of Transaction Processing Applications This section describes time per transaction, the underlying algebra expressed in centiseconds developed for processor per transaction. By selection. Different multiplying this product formulas to estimate by the transactions per the CPU time required second rate, an expression for both the application for processor utilization /database and forms is derived. Thus processor management were developed. utilization (expressed as a These formulas are used percentage scaled between separately for sizing 0 and 100 percent) is the back-end and front-end number of transactions per processors in a distributed second, times the number of configuration. The I/Os per transaction, times individual contributions of load factor x, times the the formulas are combined intensity factor. for sizing a centralized The performance goal is configuration. a CPU utilization that is The application/database less than the utilization is the work that takes specified by the customer. place on the back-end Therefore, the calculation processor of a distributed used to derive the load configuration. It is a factor is the utilization function of physical disk percentage provided by the accesses. To determine the customer, divided by the minimal CPU time required number of transactions per to handle this load, second, times the number of processor utilization is I/Os per transaction, times used as the performance the intensity factor. goal, setting up an Once computed, the load inequality that is solved factor is compared to those to obtain a corresponding values in the base load load factor. The resulting factor table. The base load factor is then load factor equal to or compared to the table less than the computed of base load factors to value is selected, and its obtain a recommendation corresponding processor for a processor type. To type, x, is returned as the reinforce this dependence minimal processor required of load factors on to handle this workload. processor types, load factor x refers to the The four input parameters associated processor that need to be estimated type x in the following for inclusion in this calculations. inequality are One method for estimating o Processor utilization the average CPU time per performance goal transaction is to multiply (traditionally set at the number of I/Os per around 70 percent, but transaction by the load may be set higher for factor x and the intensity Digital's newer, faster factor. This yields CPU processors) Digital Technical Journal Vol. 3 No. 1 Winter 1991 9 Tools and Techniques for Preliminary Sizing of Transaction Processing Applications o Target transactions per where y equals the CPU second (which may be time for forms processing; derived from Digital's a equals the CPU time multilevel mapping of per form per transaction business metrics) instance, depending on o I/Os per transaction the forms manager used; b (estimated from equals the CPU time per application description field per transaction and database expertise) instance, depending on o Intensity factor the forms manager used; z (estimated from equals the expected number experience with similar of fields; and c equals the applications) scaling ratio, depending on the processor type. Note: Response time This equation was developed performance goals do not by feeding the results of appear in this formula. controlled forms testing This sizing formula deals into a linear regression strictly with ensuring model to estimate the adequate processor CPU cost per form and per capacity. However, these field (i.e., a and b. The performance parameters multiplicative term, c, (including the CPU service is used to eliminate the time per transaction) dependence of factors a and are fed into an analytic b on the hardware platform queuing solver embedded used to run these tests. in some of the transaction processing sizing tools, Sizing Tools which produces estimates of Several sizing tools were response times. constructed by using the Forms processing is above formulas as starting the work that occurs points. These tools differ either on the front-end in the range of required processor of a distributed inputs and outputs, and configuration or in a in the expected technical centralized configuration. sophistication of the user. It is not a function of The first tool developed physical disk accesses; is for quick, firstrather, forms processing approximation processor is CPU intensive. To sizing. Currently embodied estimate the CPU time (in as a DECalc spreadsheet, seconds) required for forms with one screen for processing, the following processor selection and one simple linear equation is for transactions-per-second used: sensitivity analysis, it can handle back-end, fronty = c(a + bz) end, or centralized sizing. The first screen shows the range of processors required, given the target processor utilization, target transactions 10 Digital Technical Journal Vol. 3 No. 1 Winter 1991 and Techniques for Preliminary Sizing of Transaction Processing Applications per second, expected product characteristics number of fields, and (e.g., processor and the possible intensity disk) and measured DECtp factors and number of applications. The user I/Os per transaction. can search through the (Because the estimation measured cases to find a of these last two inputs similar case, which could generally involves the then be used to provide most uncertainty, the a starting point for spreadsheet allows the estimating key application user to input a range parameters. The built-in of values for each.) The product characteristics second screen turns the shield the user from the analysis around, showing numeric details of the the resulting transactionsizing algorithms. per-second ranges that A third tool is a spincan be supported by the off from the second tool. processor type selected by This tool is a standalone the user, given the target analytic queuing solver processor utilization, with a simple textual expected number of fields, interface. The tool and possible intensity is intended for the factors and number of I/Os sophisticated user and per transaction. assumes that the user The basic sizing formula has completed the level addresses issues that of analysis required to deal specifically with be able to supply the capacity but not with necessary technical input performance. To predict parameters. No automatic behavior such as response table lookups are provided. times and queue lengths, However, for a completely modeling techniques that characterized application, employ analytic solvers this tool gives the or simulators are needed. sophisticated user a A second tool embeds an quick means to obtain analytic queuing solver performance estimates and within itself to produce run sensitivity analyses. performance estimates. The complete DECtp software This tool is an automated platform necessary to run system (i.e., a DECtp the second tool is not application) that requests required for this tool. information from the user Data Collection according to the multilevel workload characterization To use the sizing tools methodology. This starts fully, certain data must from general business-level be available, which allows information and proceeds measured workloads to be to request successively used to establish the basic more detailed information metrics. Guidance in sizing about the application. unmeasured transaction The tool also contains a processing applications knowledge base of Digital's is highly dependent on Digital Technical Journal Vol. 3 No. 1 Winter 1991 11 Tools and Techniques for Preliminary Sizing of Transaction Processing Applications developing a knowledge DECtrace product can be base of real-world used to track the rate at transaction processing which events occur. application descriptions The methods for determining and measurements. The kinds the logical-to-physical of data that need to be disk I/O ratio per stored within the knowledge transaction remain open for base require the data continuing study. Physical collection tools to gather disk I/O operations information consistent with are issued based on the transaction processing logical commands from the sizing algebra. application. The find, For each transaction type update, or fetch commands and for the aggregate of from an SQL program all the transaction types, translate into from zero to the following information many thousands of physical is necessary to perform disk I/O operations, transaction processing depending upon where system sizing: and how data is stored. a. CPU time per disk I/O Characteristics that affect this ratio include the b. Disk I/O operations per length of the data tables, transaction number of index keys, and c. Transaction rates access methods used to reach individual data items d. Logical-to-physical disk (i.e, sequential, random). I/O ratio Few tools currently The CPU to I/O ratio available can provide can be derived from data on physical I/O Digital's existing operations for workloads instrumentation products, in the design stage. A such as the VAX Software knowledge base that stores Performance Monitor (SPM) the logical-to-physical and VAXcluster Performance disk I/O activity ratio is Advisor (VPA) products. the best method available [7] Both products can at this time for predicting record and store data that value. The knowledge that reflects CPU usage base in the second sizing levels and physical disk tool is beginning to be I/O rates. populated with application The DECtrace product descriptions that include collects event-driven this type of information. data. It can collect It is anticipated that, resource items from as this tool becomes layered software products, widely used in the field, including VAX ACMS monitor, many more application the VAX Rdb/VMS and DBMS descriptions will be database systems, and if stored in the knowledge instrumented, from the base. Pooling individual application program itself. application experiences As an event collector, the into one central repository will create a valuable 12 Digital Technical Journal Vol. 3 No. 1 Winter 1991 and Techniques for Preliminary Sizing of Transaction Processing Applications 2. K. Omahen, "Practical Strategies for Configuring Balanced source of knowledge that Transaction Processing may be utilized to provide Systems," IEEE COMPCON better information for Spring '89 Proceedings future sizing exercises. (1989): 554-559. 3. W. Zahavi, "A First Approximation Sizing Technique-The I/O Acknowledgments Operation as a Metric The authors would of CPU Power," CMG '90 like to acknowledge Conference Proceedings our colleagues in the (forthcoming Dececember Transaction Processing 10-14, 1990). Systems Performance Group 4. "TPC BENCHMARK Awhose efforts led to the Standard Specification," development of these sizing Transaction Processing tools, either through Performance Council product characterization, (November 1989). system support, objective5. "A Measure ofcritique, or actualTransaction Processingtool development. InPower," Datamation,particular, we wouldVol. 31, No. 7 (April 1,like to acknowledge the1985): 112-118.contributions made by Jim6. L. Wright, W. Kohler,Bouhana to the developmentW. Zahavi, "Theof the sizing methodologyDigital DebitCreditand tools.Benchmark: Methodology and Results," CMG '89ReferencesConference Proceedings(1989): 84-92.1. W. Zahavi, and J.7. F. Habib, Y. Hsu, K.Bouhana, "Business-Omahen, "SoftwareLevel Description ofMeasurement Tools forTransaction ProcessingVAX/VMS Systems," CMGApplications," CMG '88Transactions (SummerProceedings (1988):1988): 47-78.720-726. Digital Technical Journal Vol. 3 No. 1 Winter 199113=============================================================================Copyright 1991 Digital Equipment Corporation. Forwarding and copying of thisarticle is permitted for personal and educational purposes without feeprovided that Digital Equipment Corporation's copyright is retained with thearticle and that the content is not modified. This article is not to bedistributed for commercial advantage. Abstracting with credit of DigitalEquipment Corporation's authorship is permitted. All rights reserved.=============================================================================